Referring to FIG. 1, a block diagram of a network according to the conventional art is shown. As depicted in FIG. 1, a plurality of organizations 105–120 are communicatively coupled by one or more communication channels 190, 195, such as the internet or an extranet. Each organization 105–120 typically comprises a plurality of client devices 125–165 communicatively coupled to one or more servers 170–182. The servers 170–182 provide one or more resources, such as execution of applications and/or storage of information.
In the conventional art, the client 125 logs-on to a particular entity's server 170, wherein the user provides a username, password and/or the like. Based upon the username, password and the like, the server 170 authenticates the client 125 and determines the client's 125 authorization to access particular resources.
If the client 125 then tries to access resource on another server 172, establishing authentication and utilizing resources is problematic. The other servers 172–182 do not know that the client device 125 has been authenticated by a particular server 170. Furthermore, each organization 105–120 and/or server 170–182 may have a different login script, may require a different protocol, may utilize different information, may store the same information in differing structures, formats and/or the like. Therefore, the client typically has to sign onto each server 170–182 separately.
For example, a user may wish to access resources on various organizations 105–115 in the performance of their work, such as using the internet 190 to make travel arrangements. The user first logs-on to the company's (e.g., Widget Corp.) network server 170 utilizing a client device 125. The user may manually or via a script, enter their username (e.g, jdoe) and password in order to logon to the network server 170. The network server 170 provides an internet portal.
The user may then navigate using a browser to the website of an airline 115. The user will likely be required to enter their name, address and the like to book a flight. The user's address may be stored as a single field (e.g., address) in a record corresponding to the user's reservation. Similarly, the user may then navigate to a car rental agency 110 to reserve a rental car. Once again, the user may be requested to enter their name and address to reserve the car. The user's address may be stored as a plurality of fields (e.g., street address, city, state, zip code) in the record corresponding to the user's reservation. Similarly, the user may also navigate to a website of a hotel chain 120 to reserve a room. The user may be requested to enter a username (e.g, janed), password and the like to reserve the room using a corporate account.
Heterogeneous systems require various information. Some information may be common to each, while other information may be unique to one or more systems. Each system may also store the same information in various different formats. Thus, the interoperability of the various systems is problematic. Furthermore, the need to logon to each entity's server 170–172 and re-enter the same information (e.g., address, username) reduces the users satisfaction and productivity.
The need to logon multiple times is not limited to moving between multiple entities 105–120. For example, the user may login to their employer's network server 170 to access the finance server 180. The user may again be required to enter a username, password and the like in order to enter expenses, such as meals, entertainment and gas, incurred during their business travel. Along with entering a username, password and the like, the user may be required to enter their social security number, which is utilized to limit authorization to resources on the finance server 180. The financial server 180 may save the social security number in a field entitled “ssn.” The user may then wish to check their retirement account. Once again the user may be required to provide a username, password and the like to access the payroll server 182 in order to check their retirement account. Along with enter a username, password and the like, the user may be required to enter their social security number, which the server utilizes to limit authorization to utilize resources on the payroll server 182. The financial server 180 may save the social security number in a field entitled “social security.” Accordingly if different fields contain the same information, the interoperability of the systems may be limited even though the fields are substantially the same.
The Security Assertion Markup Language (SAML) specification is intended to provide a solution allowing single sign-on for secure authentication and authorization. SAML is an eXtensible Markup Language (XML) standard designed for business-to-business (B2B) and business-to-consumer (B2C) transactions.
Referring now to FIG. 2A, an exemplary SAML request/assertion according to the conventional art is shown. As depicted in FIG. 2A, SAML requests and assertions 210 are transmitted within a SOAP envelope 215 via HTTP 220.
Referring now to FIG. 2B, an exemplary SAML data packet according to the conventional art is shown. As depicted in FIG. 2B, the data packet comprises an HTTP header 250, a SOAP header 255 and a SAML payload 260. A request or assertion is encoded into the SAML payload 260. A SOAP header 255 is then generated and attached to the SAML payload 260. An HTTP header 250 is then generated and attached to the SOAP header 255 and SAML payload 260. The SAML payload containing a request or assertion may comprise an issuer identifier, an assertion identifier, an optional subject, an optional advice, a condition, an audience restriction, a target restriction, an application specific condition and the like.
Upon receipt, the HTTP header 250 is processed to provide routing and flow control. The SOAP header 255 is then processed to provide information concerning the content of the payload and how to process it. The SAML payload 260 may then be processed to provide security information.
Security Assertion Markup Language (SAML) for single sing-on functionality is intended to allow users to authenticate themselves in one domain and use the resources in another domain without re-authenticating themselves. SAML is intended to be an open and interoperable design for web-based single sign-on service functionality. However, differences in the organization and utilization of information limit the application of SAML in a heterogeneous network.